home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 4 / Apprentice-Release4.iso / Source Code / Libraries / Graphic Elements 3 / ReadMe < prev    next >
Text File  |  1995-08-28  |  7KB  |  151 lines
  1. August, 1995
  2.  
  3. This is the third "Internet" release of Graphic Elements. Since its first
  4. release about 18 months ago, the Graphic Elements system has been used in 
  5. a wide variety of software contexts, from "mainstream" animated educational 
  6. software to a truly innovative music-presentation system.
  7.  
  8. This release adds several features, including support for multiple 
  9. concurrent GEWorlds and a facility for "sharing space" in a window with
  10. other drawing routines. It also includes "SFXCtrlr", a very general
  11. special-effects controller for Graphic Elements, and "GESound", a set 
  12. of asynchronous sound routines designed for easy use with the Graphic 
  13. Elements system.
  14.  
  15. About the demo programs:
  16.  
  17. "GEDemo" shows the general capabilities of Graphic Elements. The walking
  18. figure on the balcony is digitized from video. Mirroring is used to make
  19. her walk in either direction. A horizontal slider is used to vary her
  20. walking speed. "Masking" is used on both the walker and the boy on the
  21. pogo stick for faster offscreen drawing. The use of Graphic Elements
  22. Special Effects is shown throughout, notably in the collision procedure
  23. for the cannonball where a very simple GESFX is used to make the "pogo
  24. boy" flash on and off when the ball hits him. The program also shows the
  25. use of the special "grabber" Graphic Element to manipulate other elements,
  26. how to handle scaling GEWorlds, and (if the compile-time variable
  27. TWOWORLDS is set to 1) how to put one GEWorld on top of another one.
  28.  
  29. "GEQTHack" shows how easy it is to adopt any Macintosh graphic -- in
  30. this case, a QuickTime movie -- into the Graphic Elements system. It
  31. also has a really neat dissolve-in, dissolve-out "About" box and a
  32. sample frame-rate testing routine.
  33.  
  34. GEBreakout is the same old game. It is included here mainly to show off
  35. the compactness of Graphic Elements code: the entire game (BGame.c) is
  36. only about 250 lines of C source.
  37.  
  38. All of the sample programs have been updated to use the new GESound
  39. module.
  40.  
  41. Below is the README file from the original release of Graphic Elements.
  42.  
  43.                     --Al Evans--
  44.  
  45. --------
  46.  
  47. GRAPHIC ELEMENTS
  48.  
  49. Graphic Elements is a very general, high-performance, framework-
  50. independent graphics presentation system. It offers graphic performance 
  51. comparable to that of a "sprite animation" system. At the same time, it 
  52. affords a very flexible mechanism for defining what a graphic is and does. 
  53. Anything that can be drawn on the screen can be a Graphic Element.
  54.  
  55. The Macintosh version of Graphic Elements is compatible with any Macintosh
  56. having a 68020 (or better) processor running 32-bit QuickDraw. It is
  57. not guaranteed to be compatible with system software versions prior to
  58. System 7.
  59.  
  60. Within these limitations, the Graphic Elements system is completely "legal".
  61. Any normal Macintosh window can contain a Graphic Elements "world". The
  62. code contains no "funny stuff" which may break under some future Macintosh
  63. system release.
  64.  
  65. DESIGN PHILOSOPHY
  66.  
  67. In writing the Graphic Elements system, I had four primary objectives.
  68. First, I wanted to provide the most general paradigm possible for programming 
  69. interactive graphics software. Second, I wanted to create an application 
  70. program interface for interactive graphics which will not "break", regardless 
  71. of changes in the underlying graphic engine or even in the type of computer
  72. which hosts this engine. Third, I wanted to give the application programmer
  73. a high degree of flexibility in defining "a graphic". Finally, I wanted
  74. to allow maximum reusability of graphics code. The Graphic Elements
  75. system accomplishes these objectives in the following manner:
  76.  
  77. From the viewpoint of the application programmer, a Graphic Element is
  78. an independent software object which knows how to image itself on
  79. demand into an offscreen workspace. Each Graphic Element may optionally
  80. have ways of reacting to 1) the passage of time, 2) contact with
  81. another Graphic Element, and 3) the user's actions. These methods will
  82. be called automatically by the Graphic Elements system, as required. In
  83. addition, the application program can act on Graphic Elements explicitly
  84. at any time.
  85.  
  86. This provides a great degree of separation between the "main line" of
  87. a program's code and its graphics code. After initialization, the 
  88. application (or the view or pane object, if a class library is being used) 
  89. needs only two calls to the Graphic Elements system to run a window full 
  90. of animated graphics.
  91.  
  92. This simplification is feasible because the Graphic Elements system allows
  93. any graphic to be defined as a Graphic Element. In order to do this,
  94. the application need only define a function which will draw the element
  95. into its current rectangle in an offscreen graphics workspace provided
  96. by the Graphic Elements system.
  97.  
  98. The Graphic Elements approach leads to a style of programming in which
  99. elements, or associated groups of elements, are defined in individual
  100. "scene" modules containing all the routines used to initialize and
  101. run the elements in the "scene". Such scenes can easily be moved from
  102. one program to another by simply including them in the new program
  103. and calling their initialization routines.
  104.  
  105. DESIGN LIMITATIONS
  106.  
  107. In order to maximize versatility and generality, Graphic Elements
  108. uses a "double-buffered" drawing system, in which the "scene" is
  109. first assembled in an offscreen workspace, then copied to the screen.
  110. By its nature, such a system imposes a cost in memory (requiring an
  111. offscreen area the same size as the onscreen "world") and in time
  112. (due to the requirement for copying from offscreen to onscreen).
  113.  
  114. The significance of the time cost, in a given situation, depends on
  115. the processor speed, the video-display hardware, the required frame-
  116. generation rate, and the area of the screen which must be updated for
  117. each frame. As a rough indication, animating 32 graphics, each 32X32
  118. pixels, on each frame, the current version of Graphic Elements can
  119. generate 31 frames per second on a Quadra 800, and 8 fps on a IIsi.
  120.  
  121. THE FUTURE OF GRAPHIC ELEMENTS
  122.  
  123. I designed the Graphic Elements system according to my vision of the
  124. future of interactive-graphics programming. In doing so, I implicitly
  125. accepted the speed disadvantage and memory cost of doing things in a very 
  126. general way. I am convinced that these costs are bearable, even in
  127. the current generation of machines. With the advent of the PowerPC and
  128. other RISC-based machines, they will become insignificant.
  129.  
  130. The generality obtained by accepting these costs pays off in other, more 
  131. important ways. The same Graphic Elements "scene" source can already be 
  132. compiled under MPW C or C++, Think C 6.0, and Symantec C++. The compiled 
  133. code can be utilized from a normal application or from one based on the MacApp 
  134. or TCL class libraries. A scene module can be "adopted" into another
  135. application program by including its header file, linking it in, and
  136. calling its initialization routine.
  137.  
  138. I have no corporate sponsor, and I have exhausted my available resources
  139. in creating the present version of Graphic Elements. However, the
  140. underlying architecture of Graphic Elements is designed to be portable,
  141. not only across application-development environments, but across platforms
  142. as well. If anybody who reads this has the means and/or ability to adapt
  143. the Graphic Elements system to other platforms such as Windows or X, I
  144. would like to hear from you.
  145.  
  146.                     --Al Evans--
  147.                       al@powertools.com
  148.                       CompuServe: 72167,2253
  149.                       Mail: Powertools
  150.                           1206 Karen Ave.
  151.                         Austin, TX 78757